1. Field of the Invention
This invention relates generally to the storage, archiving, and retrieval of medical images and video, and more particularly to improvements in a Picture Archiving and Communications System (PACS), providing to such systems ACID (atomicity, consistency, isolation, and durability) characteristics as well as versioning and other reliability enhancing features within the context of the medical image objects.
2. Description of the Related Arts
A PACS is a system for the storage, retrieval, and display of medical images. A PACS typically consists of one or more networked computers along with a substantial amount of semi-permanent digital storage in the form of, for instance, a RAID (redundant array of inexpensive hard disks), tape storage, or optical disks. A PACS also typically includes software for storing, retrieving, and displaying images, along with hardware that may be necessary for physical management of digital media (e.g., a robotic tape loader), display, and input.
A PACS is typically connected to an imaging device such as a CT (computerized tomography) scanner, an MRI (magnetic resonance imaging) scanner, or an X-ray machine capable of providing images in digital format, often including images compliant with the DICOM (digital imaging and communications in medicine) format. A doctor or other health care provider uses the imaging device to create a digital picture of a patient for diagnosis or treatment purposes. The image is delivered via a network to the PACS, where it is stored along with information identifying the particular patient. The image is viewed on the PACS immediately or it is retrieved for display later. The image is optionally processed prior to storage, or it is stored in a raw digital format and subjected to optional processing later.
Prior to the development of PACS technology, hospitals typically stored medical images on film that had to be catalogued and retrieved by hand. Early computerized medical imaging devices were flawed because the machines were typically standalone devices with no or limited archival capabilities and proprietary file formats. PACS, along with the standard DICOM and other file formats, provided a convenient, standardized way to store medical images with fast, electronic retrieval, more convenient backup, and potential for remote electronic distribution.
Despite their advantages, traditional PACSs have numerous shortcomings. First, a traditional PACS stores images, but does not store other non-graphical components of a patient's medical record such as diagnoses, examination notes, etc. Storing exam notes and other parts of the record separately from the images increases the chance that the records and images will become out-of-sync. If the PACS does store non-graphical components of the medical record, or stores ancillary information about the images such as patient name, exam, timestamp or image size, it typically does so in a relational database. However, the images themselves are typically stored on the file system of a computer rather than in the database. Because standard file systems are not protected by the two-phase commit procedure or other established ACID standards that guarantee transactional integrity in a modern relational database, an update might succeed on the medical record or ancillary information but fail on the image, or vice-versa. The record or ancillary information would then be out-of-sync with the image. Complex reconciliation algorithms might be necessary to ensure that records and images are in sync, as this type of processing lacks synchronicity. The lack of guaranteed transactional integrity between the file system and indexed information is compounded when images, records, and ancillary information are manipulated by backup, caching, and migration processes. Providing a widely-understood programmatic means of guaranteeing transactional integrity across both the medical image objects and the information about them through a commit/rollback procedure would greatly improve robustness and improve the safety of automated PACS procedures, while avoiding maintenance procedures. Medical image storage in current PACSs is not performed in a manner that ensures ACID characteristics such as can be provided by database storage using two-phase commit.
Next, storing images in the file system(s) makes it difficult to build a distributed PACS. A relational database package may operate in a distributed fashion, automatically hiding the distributed nature of the system from the user and providing a single integrated “view” of the database. Storing the entirety of the medical data, including metadata and images, in a relational database would therefore allow for simpler creation of a distributed PACS.
Further, file systems are vulnerable to virus attacks. Relational databases provide a greater level of protection against viruses. Thus, a PACS that stores its images in a relational database provides an inherent shield against viruses that might otherwise corrupt the image files. File systems are also vulnerable to unauthorized access: a hacker might obtain access to a PACS and view a patient's records without authorization. While a relational database cannot provide complete protection against unauthorized access, most databases provide an authentication system and store their data in an obfuscated format such as Oracle's varBinary format and SQL-Server 2005's two-way x509 encryption. Storing images in a relational database therefore provides protection against unauthorized access.
Additionally, where images are stored “naked” in the file system, they may be easily manipulated by other processes without the knowledge of the database. For instance, an image might be accessed and cropped by a process outside the database. The image size and last-edited date stored in the database would then be incorrect. This could be a problem for several reasons. For example, some diagnostic procedures might require images of a certain size. Users who tried to run the procedure on images whose actual size differed from that recorded in the database would encounter an unexpected and perplexing error. For another example, a doctor relying on an erroneous last-edited date could have an incorrect understanding of the speed of progression of a disease. Moving the medical images into the database forces all image manipulation to go through the database. Processes within the database (such as Oracle PL/SQL routines) may then be run automatically in response to all image updates to ensure that ancillary information about the image is kept up-to-date. The image cannot be altered without the database knowing about it, and the user need not worry about manually updating other records such as image size or date of last alteration. Another concern if the images are not controlled through the database is legal compliance, as HIPAA provisions may be violated under approaches that do not provide robust auditing of image access and manipulation.
More generally, lack of integration of image information with a single database system raises various concerns with respect to reconciling exceptions, ensuring that information remains up-to-date, general transactional integrity and the like. Broadly speaking, lack of integration means that identical or related information is located in two places, which inherently introduces risk and complexity.
Prior art PACSs do not disclose remedies for these problems. Systems are known to integrate display of both medical images and non-graphical elements of a patient's medical record such as diagnoses and examination notes. For instance, U.S. Pat. No. 6,434,569 discloses a system for combining a patient's medical record and images on one display. But such systems do not integrate the storage of the disparate sets of data. Nor do such systems provide two-phase commit to guarantee that information updates have ACID characteristics. Thus, such systems may allow images and non-graphical data to get out-of-sync.
U.S. Pat. No. 5,272,625 discloses a medical image management system comprising multiple databases storing medical images, with one directory server tracking which patients' images are stored on which databases. The patent does not disclose a relational database with two-phase commit to guarantee that updates of images and non-graphical data are atomic. This is significant, again, primarily because lack of atomicity may allow images and non-graphical data to get out-of-sync or be corrupted by concurrent updates by other processes. Nor does the patent disclose a system in which, because images are stored in database tables rather than the file system, the database software might elect to store the images in multiple sets of blocks across multiple database servers without altering the appearance of contiguous data storage to the user. This limits the known PACS to potentially inefficient use of disk space and network bandwidth.
U.S. Pat. No. 6,529,757 describes a PACS in which images are processed to varying degrees before being stored in a database. Again, the patent does not disclose storing the images in a relational database with two-phase commit. The multi-stage processing disclosed in the patent stores only one instance of the preprocessed image rather than multiple instances of the same image or images of the same body part taken at different times. Thus, it does not allow doctors to easily track the progression of diseases or healing through a series of images or allow for robust editing of images and correction of errors.
Therefore, there is a need for a PACS capable of storing image data in a relational database with transactional integrity guaranteed by two-phase commit. There is also a need for a PACS capable of storing both images and non-image data such as examination notes and a medical record in the same database.